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Mechanism for network-initiated information transfer 

The invention relates to methods and equipment for providing net- 
work-initiated information transfer for terminals in a network supporting packet- 
switched communications. The invention is suitable for example for providing 
5 push services for mobile packet radio users. Push services are services the 
availability of which is informed to the client (subscriber) by the service pro- 
vider or the network operator. Alternatively, the service provider or the opera- 
tor can deliver the service to the client. 

Background of the invention, 

10 For providing new services, there are generally two major architec- 

tures: client-server and push services. Ctient-sen/er architecture relies on the 
client's (i.e. the user's) activity for receiving new services. In contrast, with 
push service architecture the user is at least informed of the availability of new 
services by the service provider or the network operator. Instead of, or in addi- 

15 lion to, merely informing the user, the service provider or the network operator 
can actually download a new service or information to the user's terminal 
equipment. 

Fig. 1 is a block diagram of a packet radio network, such as GPRS 
(General Packet Radio Service). The GPRS infrastructure comprises support 

20 nodes, such as a GPRS gateway support node (GGSN) and a GPRS serving 
support node (SGSN). The main functions of a GGSN node involve interaction 
with the external data network. The GGSN updates the location directory using 
routing information supplied by the SGSNs about the location of an MS and 
routes the external data network protocol packet encapsulated over the GPRS 

25 backbone to the SGSN currently serving the MS, It also decapsuiates and for- 
wards external data network packets to the appropriate data network and han- 
dles the charging of data traffic. 

The main functions of the SGSN are to detect new GPRS mobile 
stations in its service area, handle the process of registering the new MSs 

30 along with the GPRS registers, send/receive data packets to/from the GPRS 
MS, and to keep a record of the location of the MSs inside of its service area. 
The subscription information is stored- in a GPRS register (Home Location 
Register HLR) where the mapping between a mobile station identity (such as 
MSISDN or IMSl) and the PDP address is stored. The GPRS register acts as a 

35 database from which an SGSN can ask whether a new MS in its area is al- 
lowed to join the GPRS network. 
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The GPRS gateway support nodes GGSN connect an operator's 
GPRS network to externa! systems, such as other operators' GPRS systems, 
data networks 11, such as an IP network (e.g. the Internet) or an X.25 net- 
work, and service centres. Fixed hosts or servers 14 can be connected to a 

5 data network 1 1 for example by means of a local area network LAN and a 
router 15. A border gatev^ay BG provides an access to an inter-operator 
GPRS backbone network 12. The GGSN may also be connected directly to a 
private corporate network or a server. The GGSN contains GPRS subscribers' 
PDF addresses and routing information, i.e. SGSN addresses. Routing infor- 

10 mation is used for tunnelling protocol data units PDU from the data network 1 1 
to the current switching point of the MS, i.e. to the serving SGSN. The func- 
tionalities of the SGSN and the GGSN may be located in the same physical 
node. 

The home location register HLR of the GSM network contains 
15 GPRS subscriber data and routing information and it maps the subscriber's 
IMSI into one or more pairs of the PDP type and PDP address. The HLR also 
maps each pair of a PDP type and a PDP address into a GGSN node. The 
SGSN has a Gr interface to the HLR (an SS7 signalling connection). The HLR 
of a roaming MS and its serving SGSN may be in different mobile communica- 
20 tion networks. 

The intra-operator backbone network 13, which interconnects an 
operator's SGSN and GGSN equipment can be implemented, for example, by 
means of a local area network. It should be noted that an operator's GPRS 
network can also be implemented without the intra-operator backbone net- 
25 work, for example by providing all features in one computer. 

A general problem underlying the invention is that packet data us- 
ers generally do not have permanent addresses, such as IP (IPv4 or IPv6) ad- 
dresses. The reason is the limited address space of especially IPv4, which 
justifies the common practice of allocating IPv4 addresses to the user dynami- 
30 cally only when needed, and thus reusing the same address among different 
users. On the other hand, this practice makes provision of push services 
rather difficult. 

A more specific problem can be seen in packet radio networks, 
such as GPRS, or in the 3rd generation systems, such as UMTS (Universal 
35 Mobile Telecommunications System). Such packet radio networks provide the 
user with a packet data protocol (PDP) address which can be used for routing 
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packets to/from a mobile station in the network currently serving the user. This 
network may be a visited network VPLMN (Visited Public Land based Mobile 
Network), i.e. a network different from the user's home network HPLMN 
(Home PLMN). The PDP address can be an IP address or an X.25 address or 

5 equivalent. The PDP address may be static or dynamically allocated by the 
serving network. In the first case, the GGSN is located in the home network, 
whereas in the latter case the GGSN in the visited network can be used. The 
specific problem is that in the case of dynamic PDP address allocation, only 
the serving network knows the user's PDP address, such as the user's current 

10 !P address (or any other address). This is not a problem in client-server archi- 
tectures, because the client (having the initiative) knows the server's address. 
In push service architectures, however, this is a problem because the 
server/service provider does not know where to "push" new services or infor- 
mation about them. 

1 5 Disclosure of the invention 

An object of the invention is to develop mechanisms for providing 
push services in a packet radio system, in other words, the invention should 
solve or at least minimize the problems associated with the prior art push 
service mechanisms. The object is achieved with a method and equipment 

20 which are characterized by what is disclosed in the attached independent 
claims. Preferred embodiments of the invention are disclosed in the attached 
dependent claims. 

The invention is based on locating the problem and finding a solu- 
tion for it. The solution is based on the vision that a packet radio network is 

25 supplemented with intelligent Network (IN) technology. For a given area where 
the invention is to be implemented, the serving support nodes covering that 
area are operationally connected to an Intelligent Network node. The IN can 
be used as a data store for storing an address or an identifier by which the 
mobile station can be reached. Preferably, such an address or identifier is the 

30 PDP address of the MS, Within the context of the present application, the PDP 
address of a mobile station (MS) refers to any address, number or other iden- 
tifier by which PDP packets may be routed to the MS. 

While such a hybrid between a packet radio network and an intelli- 
gent network might seem desirable, implementing such a hybrid is far fronn ob- 

35 vious. IN standards have been created for wired connection-oriented tele- 
communications networks. Implementing IN functionality is problematic in a 
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mobile teiecommunications network wherein the mobile subscriber lacks a 
fixed access point Yet nnobile subscribers subscribing to IN services should 
be identified everywhere in the mobile telecommunications network, and 
knowledge about their services should be maintained, etc. This easily leads to 

5 massive data files and/or a need for extensive data transfer within the mobile 
teiecommunications network. For instance, in the GSM (Global System for 
Mobile Communication) system, maintaining a connection to the Service Con- 
trol Point SCP of the IN is implemented such that when a subscriber moves 
from the area of one Mobile services Switching Centre (MSG), acting as an IN 

10 Service Switching Point SSP, to the area of another MSG, the original MSG 
remains a controlling anchor centre to which information about events in the 
new MSG are transferred using MAP protocol. In such a case, the connection 
to the IN SCP may remain in the original MSG. In contrast, a packet radio 
system, such as the GPRS system which is used as an example, lacks any 

15 anchor node which would correspond to an anchor centre, and the control 
over a packet data connection is moved when the subscriber moves from the 
area of a support node, acting as an IN SSP. to the area of another support 
node. In such an arrangement, a relevant problem is maintaining the states of 
the Service Logic Programs (SLP) of the IN SCP corresponding to the con- 

20 nection as the support node changes. Maintaining the states is essential in or- 
der for the original SLP to be able to control the packet data connection in a 
seamless manner, even though the subscriber is moving in the areas of differ- 
ent support nodes. 

Reference 1 discloses a solution for this specific problem. However, 

25 reference 1 had not been published on the priority day of the present applica- 
tion, and its main points are repeated here. 'Service connection' refers to a 
connection which is set up for the purpose of providing services. When the 
service connection is established between the IN SCP and a first SSP, an 
identifier is allocated to the service connection. When the subscriber moves 

30 from the area of one SSP to the area of another SSP. the identifier of the 
service connection is transferred from the old SSP to the new SSP. preferably 
with the address of the SCP and the state information of the SSP. By means 
of the transferred data, a service connection is established from the new SSP 
to the SCP, and the SLP corresponding to the service connection is identified 

35 by means of the identifier of the service connection. Even if the support node 
serving the subscriber changes, the corresponding SLPs maintain their state 
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information. Thus the same SLP can control the service connection for its en- 
tire duration, although the senyice connection would have to be re-established 
because the SSP changes. 

Using IN technology in a packet radio network poses another prob- 
5 lem. The concept of IN technology is based on modelling a call with a Basic 
Call State Model (BCSM), but in a packet radio network there is no "call". 
Rather, packets are sent and received as necessary. Reference 2 discloses a 
solution for this specific problem, but reference 2 had not been published on 
the priority day of the present application, and its main points are repeated 

10 here. Several IN concepts can be used, however, if an analogy of a BCSM is 
created, but instead of a call, the analogy model is used to model a session in 
a packet radio network. At least one event in a packet radio network should be 
defined as a trigger event which triggers a service request into a Service Con- 
trol Point (SCP) of the IN, 

15 At first sight, implementing IN technology seems to require exten- 

sive modifications in a packet radio network, considering that for the purposes 
of the present invention the !N is only needed as a data store (or a front end to 
a data store) for storing an MS-related address or identifier. However, the in- 
vention is partly based on a vision that IN technology can be used for provid- 

20 ing many other services besides delivering push sen/ices (such as advanced 
charging), and consequently, these extensive modifications can be justified. 

According to a preferred embodiment of the present invention, the 
packet radio network is modified as follows. A suitable interface, such as an 
INAP (Intelligent Network Application Part) or a CAP (Camel Application Part) 

25 interface is defined between a GPRS support node (preferably an SGSN 
node) and an Intelligent Network node. Preferably, such an IN node is a Serv- 
ice Control Point SCP of the IN. The address of the SCP is indicated for ex- 
ample in the user's subscriber data. The GPRS support node is programmed 
to inform the SCP of the PDP address allocated to the user for example upon 

30 a successful PDP context activation. This message sent to the SCP may also 
include other information, such as information about the QoS class related to 
the PDP context or location information. When the user is detached from the 
network, or when the PDP address is cancelled or reallocated, the SCP is no- 
tified again, 

35 The SCP is programmed to maintain an association between a sub- 

scriber identity (e.g. IMSl) and the PDP address allocated to the user. A server 
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providing a subscriber with a new push service sends an inquiry to the SCP. 
The SCP responds by sending the PDP address of the user. The response 
can also include other data related to the PDP context, such as location infor- 
mation. 

5 The invention can be used to implement push services including, 

but not limited to: 

notification about current call tariffs, 
notification about new messages in the user's mailbox, 
notification about new messages in a voice processing system, and 
10 notification about local facilities in the user's location area. 

As an example, let us consider the case where the MS subscriber 
subscribes to a certain service, such as a weather forecast or stock market 
data. The server can actually provide the subscriber with the weather forecast 
or stock market data. Alternatively, the sen/er may only inform the subscriber 
15 that a new forecast or new data is available. It is also possible to download 
executable program code, such as Java applets or the like, to the MS. 

Brief description of the drawings 

The invention will be described in more detail by means of preferred 
embodiments with reference to the appended drawing in which: 
20 Fig. 1 is a block diagram showing some elements of a packet radio 

network which are essential for describing the invention; and 

Figs. 2A and 2B are signalling diagrams illustrating different em- 
bodiments of the invention. 

Detailed description of the mvention 

25 As shown in Fig. 1, the packet radio network is supplemented with 

Intelligent Network (IN) technology. The packet radio network is preferably 
modified as follows. An INAP (Intelligent Network Application Part) interface is 
defined between a GPRS support node (preferably an SGSN node) and the 
SCP of the IN. In other words, the support node is equipped with an IN Service 

30 Switching Function SSF. A network element having SSF functionality is called 
a Service Switching Point (SSP). The address of the SCP can be indicated in 
the user's subscriber data. A state model can be formed of the PDP context 
activation. (In circuit-switched networks, state models are generally used for 
modelling a call. In a packet-switched network, the concept of a "call" does not 

35 exist, but an analogy of a state model can be used for modelling for example a 
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session which begins when the MS attaches to the network and ends when 
the MS is detached from the network.) The support node with the SSP func- 
tionality, typically an SGSN/SSP node, is programmed to inform the SCP 
about the PDP address allocated to the user. When the user is detached from 
5 the network, or the PDP address is cancelled or reallocated, the SCP is noti- 
fied again. 

The SCP is modified as follows. It may comprise a proprietary in- 
terface (such as TCP/IP over Ethernet) to the server equipment for providing 
push services. A suitable Service Logic Program SLP is installed in the SCP. 
10 The purpose of this SLP is to create, maintain and delete an association be- 
tween the identity and the PDP address of a mobile station. A server, such as 
the server 14, providing a subscriber of the MS with a new push service sends 
an inquiry to the SCP. The SCP, using the SLP, responds by sending the PDP 
address of the MS. 

15 Fig. 2A is a signalling diagram illustrating a preferred embodiment 

of the invention. In step 2-2, the MS sends an Attach Request to an SGSN 
node, in step 2-4, the network activates a PDP context for the MS. It should be 
noted that steps 2-2 and 2-4 normally comprise many different operations, 
such as authenticating the MS subscriber and sending an acknowledgement 

20 to the MS. However, for clarity such routine operations are not shown sepa- 
rately. According to a preferred embodiment of the invention, the prior art acti- 
vation procedure is modified so that in step 2-6, in response to the PDP con- 
text activation, the SGSN sends the SCP a start-up message for launching an 
IN service. In INAP terminology, the start-up message is called an IDP (Initial 

25 Detection Point). Its parameters comprise a service key Skey for identifying 
the IN service, a subscriber identity IMS!, and the PDP address of the MS. 
Upon receiving the IDP with these parameters, the SCP executes the Service 
Logic Program SLP associated with the Skey. This SLP creates and maintains 
an association between an MS/subscriber identity (such as the IMSl) and the 

30 corresponding PDP address. 

Next, it is assumed that in step 2-8 the server 14 decides to inform 
the MS about a new or updated service. In step 2-10, it sends the SCP an in- 
quiry concerning the PDP address ' of the MS. This inquiry is called 
PDP_Address_Request and its parameters comprise the MS IMSL In step 

35 2-12, the SCP replies by sending to the server the PDP address of the MS. 
The reply message is called PDP_Address___Acknowledge. Finally, in step 
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2-14, the server 14 knows the current PDP address of the MS and it can send 
a message addressed to the MS. For clarity, details of the routing of the mes- 
sage 2-14 are not shown separately. Such routing can be performed by nor- 
mal GGSN/SGSN functionality. 
5 As an alternative, it is not necessary to route the message 2-14 via 

the GGSN node. Instead, the server 14 having a Gn interface may be located 
in or connected to the operator's private backbone network 13 and the ad- 
dress information may include the OTP tunnel identifier (Tl) and SGSN ad- 
dress of the MS, in addition to the PDP address, 

10 In the embodiment shown in Fig. 2A, the SOP is only used as a 

data store for storing the PDP address of the MS. (Alternatively, if the PDP 
address is stored in some external database, the SCP may be used as a front 
end to such a database.) An essential feature is that the server 14 does not 
have to keep track of the changing PDP addresses of individual mobile sta- 

15 tions, and it is sufficient for the server to know the address of the SCP. Upon a 
successful PDP context activation or update, the SGSN node serving the MS 
informs the SCP of the PDP address allocated to the MS. Later, in step 2-10. 
the server sends the SCP an inquiry about the PDP address of the MS, but the 
actual push service or information about it is not routed via the SCP. The em- 

20 bodiment shown in Fig. 2A has the advantage that the server knows the PDP 
address of the MS and bi-directional communications can be established be- 
tween the server and the MS. However, the PDP address discloses something 
of the MS's location and some subscribers might object to such a disclosure 
as trespassing on their privacy. According to an alternative embodiment 

25 shown in Fig. 2B, steps 2-10' to 2-12' are modified such that the actual push 
service or information about it is routed via the SCP. No messages for this 
purpose have been standardized, but step 2-12' is somewhat analogous to 
using ConnectToResource and PlayAnnouncement operations in a circuit- 
switched network. An advantage of this alternative embodiment is that no in- 

30 formation about the MS location is revealed to the server which might be out- 
side the PLMN. 

The description only illustrates preferred embodiments of the inven- 
tion. Based on the above description, certain modifications are apparent to a 
skilled reader. For instance, according to yet another embodiment, the SCP 
35 may store information about servers providing push services to the users, and 
in response to receiving information about the current PDP address allocated 
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to a certain user (such as activation or deactivation of the PDP address), the 
SCP sends this information to the servers (e.g. by multicasting). Mobile sta- 
tions with a radio interface have been used as a concrete example of mobile 
terminals, but the invention is equally applicable in a wired packet-switched 
5 telecommunications network. Thus, the invention is not limited to these exam- 
ples or the terms used, but it may vary within the scope of the appended 
claims. 
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